Understand data residency

This feature is available for Jira, Jira Service Management, Jira Product Discovery, and Confluence with Enterprise, Premium, and Standard plans.

Data residency gives you control over where your in-scope product data for Jira, Jira Service Management, Jira Product Discovery, and Confluence is hosted. It allows you to choose whether it’s globally distributed or held in place in a defined geographic location, such as Europe or the US.

If you work in a regulated industry like finance, government, or healthcare, data residency may be a necessity for operating in a cloud environment. More generally, it can also help you meet company data management requirements.

View where your product data is hosted

You can view where your in-scope product data is hosted from your organization administration. You must have organization admin permissions to do this.

To view where your product data is hosted:

Go to admin.atlassian.com. Select your organization if you have more than one.
Select Security > Data residency.

This will open the data residency page for your organization. This page lists the products in your organization, the location of each product, and the AWS regions the location corresponds with. If a product is PINNED to a location, its in-scope data is held there.

If data residency is available for your product, you can request to have its in-scope data moved and pinned to a new location. To learn more about this, see Move data to another location.

To protect your data, we create automated Amazon Relational Database Service (RDS) backups daily. When you choose a data residency location, we also store backups of your data in this location. Learn more about how we manage your data

What are locations and AWS regions?

A product’s location is the geographical boundary where its in-scope data is hosted. Each location corresponds with one or more AWS regions, which are physical locations around the world where AWS clusters its data centers. Learn more about AWS infrastructure and its role in our cloud hosting infrastructure.

The following locations are available for you to select from:

Location	AWS regions
Global	All Atlassian cloud across AWS regions
Australia	Consists of Australia (Sydney) region
Canada	Consists of Canada (Central) region
EU	Consists of Europe (Frankfurt) and Europe (Dublin) regions
Germany	Consists of Europe (Frankfurt) region
India	Consists of Asia Pacific (Mumbai) regions
Japan	Consists of Asia Pacific (Tokyo) region
Singapore	Consists of Asia Pacific (Singapore) region
South Korea	Consists of Asia Pacific (Seoul) region
Switzerland	Consists of Europe (Zurich) region
United Kingdom	Consists of Europe (London) region
USA	Consists of US East (North Virginia) and US West (North California) regions

By default, all products are hosted in the Global location, which includes all of our AWS regions. For these products, we determine where their in-scope data is located. To optimize product performance, we don’t limit data movement for these products, and we move data between AWS regions as needed.

If you require your in-scope product data to stay in a specific location, and data residency is available for your product, you can request to have its in-scope data moved to a location and pinned there. Learn more about moving your product to another location

As detailed in the next section, some locations don't support all capabilities.

Limitations for some locations

Switzerland

The Atlassian Data Lake is not available for this location. If you pin your data to this location, the following limitations will apply until these capabilities are available in this location.

Atlassian Analytics charts and dashboards for Jira, Jira Service Management, and Confluence Enterprise plans won't be available for data that has moved to this location.
Opsgenie reports embedded into Jira Service Management for all paid plans will not be available for data that has moved to this location. This limitation will persist and you will not be able to access your data pinned to this location even if you move your data back to its previous location.
Assets Report embedded into Jira Service Management for all Enterprise and Premium plans won’t work for data that has been moved to this location until this service becomes available in this location.

If you're currently using or plan to use the capabilities mentioned above, we recommend that you don't pin your data to this location until these capabilities are supported. If you have an urgent requirement or need help with this location, contact support.

In-scope product data

This table lists in-scope product data types that can be pinned and out-of-scope product data that can’t. For definitions of these data types, see the glossary.

Product	✅ Can be pinned	❌ Can’t be pinned
Jira	All attachments Board and sprint data Comments In-product notification data Jira issues and field content (including system and custom fields) Jira search data Project configuration data (including workflows, custom field configuration, and board configuration)	Connected DevOps data (including commits, branches, pull requests, builds, deployments. feature flags, remote links) Product analytics
Jira Service Management	All attachments Comments In-product notification data Knowledge base category data (if integrated with Confluence) Asset object data and schema configuration data Jira issues, request types, and field content (including system and custom fields) Jira search data Data used by Chat Project configuration data (including workflows and custom field configuration) Queue data Configuration management databases (CMDB) used for the external asset platform. SLA configuration data Any incident management features powered by Opsgenie. Learn about data residency for Opsgenie. Virtual Service Agent	Customer accounts Product analytics Service Registry
Jira Product Discovery	Jira Product Discovery ideas All attachments Idea comments Fields values (except values for votes) Dynamic fields (Reactions, Custom formulas) Field configuration Jira search data In-product notification data Project configuration data	Product analytics Views configuration & comments Insights Dynamic fields (Vote fields)
Confluence	All attachments Comments Confluence page and blog data In-product notification data Page and comment likes Page metadata Source data for notifications in emails Whiteboards Databases Confluence search data	Permission and restriction configuration data Space keys
Atlassian Guard		User account information data Audit log events
All products	Some Atlassian Marketplace and app data	Some Atlassian Marketplace and app data Automation rule configuration data Cached content, such as emails and notifications (up to 30 days) Data in transit (up to 30 days) Product, audit, and operational logs Product analytics Team profile information data Third-party product integration data Transient rule execution data User account information data User analytics Migrations include both caching and in-transit data, which can’t be pinned. This data is stored for 14 days.
Atlassian Analytics and Atlassian Data Lake	Product data stored in the Atlassian Data Lake	Chart metadata (including chart titles, settings, annotations, queries, and comments) Dashboard metadata (including dashboard titles, URL slugs, and other settings; comments; variables; subscription configuration (including email, frequency, and variables); and text elements) Data sources (including data source names and configuration data) Activity (including query logs and activity logs for dashboards and data sources)

Why we don't pin user account information data

We store user account information in a central identity service and a small, controlled set of replica services. We don’t pin these services and the user account information in them because we host them around the world to meet the performance needs of our customers.

We store user account information this way to limit its footprint in our system. It means that this information is not stored in our products at all. Instead, our products store representative IDs that they use to retrieve it from our identity services.

For these reasons, data residency can’t apply to user data at this time. We understand that this may be a challenge for some of our customers, and we are happy to help you find a solution that would work better for your data residency needs.

For more information on where and how we store user data, visit the Atlassian Trust Center.

We take privacy seriously and operate a global privacy program to meet the GDPR, CCPA, LGPD requirements, and beyond. We treat all user data the same way and use industry-standard technical and organizational measures to secure the information we store. Our Privacy Program is tailored to meet both legal requirements as well as your needs.

Learn more at the Atlassian Trust Center. Or, for information specific to the EU, read about our GDPR commitment.

How data residency works for Marketplace apps

Atlassian Marketplace is comprised primarily of apps built by third-party Marketplace partners. These partners often work closely with Atlassian and use Atlassian's tools and APIs but are not part of Atlassian. If an app supports a data residency move, you can request your data to be moved and stored within the same location as your host product.

We support a combined move of a product and some of its installed apps. While we're moving your product to its new location, some of its installed apps will move automatically. This means that some of the apps that support a data residency move will be moved along with the product. However, some apps will have to be moved separately after the product has moved to the preferred data residency location. Learn more about moving your Marketplace app data to another location

For more information on a specific app, refer to the app's listing on Atlassian Marketplace, where you will find a privacy policy, documentation, and contact information. We recommend that you go through the documentation carefully to understand what data is in-scope and out-of-scope for an app’s data residency.

How data residency works for Opsgenie features

Incident management features (previously an Opsgenie feature) are now incorporated into the Jira platform. This means that whenever you move Jira Service Management, your incident management data (previously Opsgenie data) will also become pinned to the selected location.

Sometimes, a site name conflict can prevent your data residency move. You will need to reach out to our support team to get help with your data residency move.

To get help with your data residency move,

Go to http://support.atlassian.com/ and select Contact support.
Enter your Atlassian Account email ID.
Under What can we help you with, select Technical Issues and Bugs.
Select your Opsgenie URL under the Choose from your licenses menu or select JSM under Select a product.
Fill in the details related to your request and select Submit the support request.

Data residency glossary

Term	Definition
Asset data	Third-party asset data stored in the asset platform used to synchronize with Jira functionality.
Atlassian Guard	Atlassian Guard is a subscription that you purchase for your whole company. It enables visibility and security across all Atlassian accounts and products and gives you one place to manage your users and enforce security. Understand Atlassian Guard
Atlassian Marketplace and app data	Data from Connect apps that may be stored outside of the Atlassian cloud environment by a third-party app vendor.
Attachments	Files attached or added to Jira, Jira Service Management, or Confluence issues, pages, or other content.
Audit logs	Logs generated by admin actions.
Automation rule configuration data	Data that we capture when an Automation rule is created or edited to enable us to define its behavior.
AWS region	Amazon Web Services regions. Learn more about AWS infrastructure
Cached content	Content stored in a non-specified region for up to 30 days with the purpose of: Progressive content migration to a nominated location Temporary storage of transactional content, such as emails and notifications, until delivery has been confirmed or abandoned. Temporary storage of query results and rendered charts for dashboards in Atlassian Analytics
Connected DevOps data	Data related to the Jira DevOps experience including: commits branches pull Requests builds deployments feature flags remote links
Customer accounts	User data in your customer accounts for Jira Service Management projects.
Data in transit	Data being processed or moved across, and not stored, by Atlassian store.
Incident management functionality data	The data used in functionality for the incident management feature powered by Opsgenie.
In-product notification data	Data related to Jira, Jira Service Management, and Confluence in-product notifications.
Jira Service Management features powered by Opsgenie	All features accessed through the Opsgenie URL. Some of these features are displayed in the Jira Service Management product screen.
Knowledge base category data	Categories for the Jira Service Management knowledge base, including description and configuration displayed in the portal when integrated with Confluence.
Operational logs	Atlassian system logs used for operational maintenance and diagnostic purposes.
Page metadata	The data used to describe a Confluence space for the purpose of search indexing.
Permission and restriction configuration data	Data related to the configuration of product or site access permissions or restrictions.
Pinned	Product data that is held in place in a location.
Product analytics	Events fired by our cloud products for in-product user experience optimization and performance.
Product data	Data added directly by a user.
Product data at rest	Data added directly by a user, that has persisted for 30 days or longer in our cloud data stores.
Product logs	Logs generated by Jira and Confluence product changes related to content and configuration.
Queue data	Data in customer requests triaged for teams to answer. For example, a summary, status, or customer name.
SLA configuration data	Service Level Agreement text field names, time metric configuration, calendar configuration, and JQL queries for SLA Goal configurations.
Source data for notifications in emails	Data in an email with notification details. For example, an email that contains issue names and comments.
Team profile information data	Data related to your Atlassian team profile, including: name, description, or header image all team links information and activity
Third-party product integration data	Data from any product integrated with Jira, Jira Service Management, or Confluence. For example, a Github integration.
Transient rule execution data	Data that we pass to an Automation rule, or is looked up by an Automation rule, so it can perform its actions. We only keep this data for the duration of the rule execution. It may include issue and user data.
User account information data	Personal account information including: name email address avatar
User analytics	Events fired by our cloud products to help understand experiences based on how a user interacts with products.

Was this helpful?

It wasn't accurate

It wasn't clear

It wasn't relevant

Still need help?

The Atlassian Community is here for you.

Ask the Community